"The time has come," the Walrus said, "To talk of many things: Of news -- and chips -- and Gopher hacks, Of Babbage's -- and pings."
Apologies to Lewis Carroll, but the time has come to talk of many things, all of them dependent on Apple's MacTCP. I'm going to start by discussing MacTCP itself, which Hayden licensed from Apple to put on the disk that comes with this book. I also take a quick look at Open Transport, MacTCP's successor, which is currently in testing and may be out before the next edition of this book. With those preliminaries out of the way, let's check out MacTCP 2.0.6.
Roughly speaking, MacTCP is a translator. It enables the Macintosh to speak the language of the Internet, TCP/IP (Transmission Control Protocol/Internet Protocol). Normally, of course, Macs speak AppleTalk to one another, over Macintosh networks. You must have the MacTCP control panel installed and configured properly, in order for the MacTCP-based programs such as Fetch and Netscape to work, although MacTCP does not make the connection itself. Think of MacTCP as the Babel Fish from the Hitchhiker's Guide to the Galaxy. Pop it in your Mac's ear (the Control Panel folder, actually), and your Mac understands the Internet noise that flows in and out. The metaphor of speaking and languages isn't quite accurate because TCP/IP is actually a transport protocol. But the idea of MacTCP as a Babel Fish that translates Internet gibberish into a language the Mac can understand seems to be the most understandable metaphor. Luckily, everything that MacTCP does happens at such a low level that you never notice. In fact, after you set up MacTCP correctly, you should never notice that it's present.
Once your Mac is connected to the Internet with MacTCP and a network, SLIP, PPP, or Apple Remote Access (ARA), it is essentially the same as any other Internet machine and has its own IP number. This means that you can connect to other Internet machines directly, without going through an intermediate machine. You can also, if you want, run server software to turn your Mac into an FTP, Gopher, or Web server, although that really requires a permanent Internet connection.
Note: Because the Internet is based on the TCP/IP protocols, the only way for a Mac to enjoy a full Internet connection is to use MacTCP. If you do not have MacTCP installed and a MacTCP-based connection using PPP, SLIP, ARA, or a Internet-connected network, you cannot use the MacTCP-based programs. Period.
Apple and other companies have thought in the past that MacTCP is a program that only large organizations want to buy, install, and configure. Accordingly, most of the documentation I've seen makes this assumption, too. It's a poor assumption these days, because individuals using PPP or SLIP can easily gain access to the Internet, and PPP and SLIP require MacTCP. However, if you work at a university or business that provides your Internet connection, it's a good bet that you have a network administrator who knows a great deal about MacTCP, and who has probably preconfigured it for your convenience.
Note: Evidence that this view of MacTCP is changing comes from Apple's inclusion of MacTCP in System 7.5. If you have System 7.5, even if you've never tried to connect to the Internet, you very well may have MacTCP already installed (but not configured).
In fact, a system administrator can preconfigure and then lock MacTCP (using another control panel called AdminTCP) so you can't change any of this information. I'm assuming that you want to use the version of MacTCP that I include on the disk, though, and that version enables anyone to configure it.
Because those of you with network administrators can ask them for help, I concentrate on details of interest to the individual who has no local network administrator and must rely solely on this book and the system administrator at a public provider.
Along with the help text that's built into my installer for you to save or print (and I strongly recommend you do this), you may want to browse through a document about MacTCP written by Eric Behr. It's available at:
ftp://ftp.tidbits.com/pub/tidbits/tisk/info/mactcp-info-13.hqx
This chapter may seem a bit long, and if you've skimmed through it already, involved. It is, I won't pretend otherwise. However, there's a reason for that.
There are three types of people who are reading this chapter. The first type just wants to get on the Internet quickly and plans to use one of the Internet access providers listed in appendix A, "Internet Starter Kit Providers." If you fall into this group, you should not need to configure much, if anything in MacTCP. The ISKM Installer provides preconfigured MacTCP Prep files, which contain the settings you'll need. The ISKM Installer installs a folder called "Customized MacTCP Prep Files" containing a number of other folders named for the various Internet Starter Kit providers. To configure MacTCP, just hold down the Option key (this makes a copy of the file rather than just moving it) and drag the appropriate MacTCP Prep file for your provider into your Preferences Folder in the System Folder, and then restart. Bear in mind that if you have previously configured MacTCP, the new MacTCP Prep file will replace the old one.
The second type of reader cannot work with one of the Internet Starter Kit providers for some reason, usually related to none of them being a local call. If you fall into this category, unless the provider you sign up with locally has excellent instructions, you may have to configure MacTCP from scratch. This chapter provides all the background information to help you do this -- you must still get the specific details from your provider.
Third and finally, some readers simply want to know more about how MacTCP works, or perhaps they may need to know about it to better troubleshoot some problem. I've tried to explain all the quirks that you're likely to hit in MacTCP, and in conjunction with chapter 20, "Troubleshooting Your Connection," feel that I've provided a lot of useful information that should help you if you have troubles.
So, if you work with one of the Internet Starter Kit providers, you can pretty much ignore this chapter, assuming everything works properly. Otherwise, read on!
Now, let's go over the questions that you need to ask, and get your Internet access provider to answer, before you can configure MacTCP on your own. First, of course, comes the connection method -- via PPP or SLIP, or network. If you connect via PPP or SLIP, there are a number of other questions you must ask. Before you call your provider, read through the next few chapters on PPP and SLIP (depending on which you must use, of course) to find out how to configure MacTCP. If you're connecting via a network, most of the same rules apply, but again, your network administrator knows the details. And, frankly, although you're somewhat more likely to use a Manually-addressed account when connecting via a network, things are usually easier without the added PPP or SLIP layer.
Second, find out whether you are supposed to determine your address Manually, whether it's assigned dynamically when you call the Server each time, or Dynamically at random (which is apparently seldom used, dangerous, and worth avoiding). Keep reading, but those three italicized terms are extremely important and confusing because each corresponds to a choice in the MacTCP control panel; the way people talk about the methods doesn't always correspond.
Note: Again, if you use one of the Internet Starter Kit Providers listed in appendix A, you do not need to collect any of this information!
In talking with system administrators, I find that most call Manually-addressed accounts static (because your IP address is assigned once and never changes) and Server-addressed accounts dynamic (because the server assigns you a different IP address on the fly each time you connect). You see the problem. I've never heard of anyone using a "Dynamically"-addressed account outside of a controlled laboratory situation, complete with rats, mazes, and spilled ink. (Okay, so I exaggerate slightly. But only slightly.)
If you have a Manually-addressed account, you must find out what your IP address number will be. It will be four numbers, separated by periods, and should look something like 192.135.191.128. If you connect manually, you also need a gateway address number in the same format. You may need this gateway address with a server-addressed account as well, but MacTCP doesn't allow you to enter it -- some implementations of SLIP do. Depending on the configuration of your site, you may also need to find out your network class and subnet mask, and your network administrator should know what to tell you here. People who use PPP and SLIP do not, for the most part, ever need to configure the network class and subnet mask part of MacTCP.
No matter what, you need to know the numeric IP addresses of one or more domain name servers, which are machines that translate between names that you enter, such as nwnexus.wa.com, and the numeric addresses that the machines all use, such as 192.135.191.1. Finally, although you don't need them to configure MacTCP, now is a good time to ask your system administrator for the addresses of your SMTP (Simple Mail Transport Protocol) and NNTP (Net News Transport Protocol) servers. Also ask your system administrator what your POP account will be, and whether it's different from your email address. See Table 17.1 for examples of each of these data.
Table 17.1: MacTCP Account Information Item Example Connection method SLIP, LocalTalk, Ethernet Addressing style Manually, Server, Dynamically IP address (if Manually) e.g., 192.135.191.128 Gateway address (if necessary) e.g., 192.135.191.253 Network class (if Manually and necessary) A, B, or C Subnet Mask (if Manually and necessary) Ask Primary and Secondary Domain Name Servers e.g., 198.137.231.1 Local domain e.g., halcyon.com SMTP mail server e.g., mail.halcyon.com NNTP news server e.g., news.halcyon.com POP account e.g., tidbits@mail.halcyon.com Email address e.g., tidbits@halcyon.com
Note: Every now and then I get a complaint from someone who says that they don't have a system administrator to ask. I hate to tell them, but unless they are in complete charge of the machine that they connect to, there must be someone else who acts as the system administrator. You cannot set this stuff up entirely on your own -- you must have the cooperation of the person who runs the machine to which you connect. This person usually works for the organization that provides your Internet access, such as a university information technology department or a company like Northwest Nexus, the Internet access provider I use.
I realize this information is a bit much to swallow at once, but that's why I go over how to configure MacTCP in the following section, so that you can see where each piece of information goes. Also, check out the worksheet at the back of the book -- you can fill it in with your information to make it easier to set up MacTCP, and, if you use either, PPP or SLIP.
To start, copy the MacTCP control panel to the Control Panels folder in your System Folder. If you drag it to the System Folder icon, System 7 (or later, of course) copies it to the right place.
Note: If you are upgrading from a previous version of MacTCP, write down all of your settings. Then, make sure to delete the old MacTCP control panel, the MacTCP DNR file that lives loose in the System Folder, and the MacTCP Prep file that lives in your Preferences folder. If you fail to delete these items before you install the new version, there's no telling what could go wrong.
If you plan to connect via PPP or SLIP, take a moment and install MacPPP or InterSLIP, because you cannot finish configuring MacTCP without MacPPP or InterSLIP installed. I'm going to crib a few paragraphs from the MacPPP and InterSLIP installation sections, so don't be surprised if this information sounds familiar later.
Note: Again, the ISKM Installer places the various parts of MacPPP and InterSLIP in the proper folders automatically. If you get a new version of either, though, you may need these instructions to know where the different files live. Note also that all the Internet Starter Kit Providers use PPP, not SLIP.
Installing MacPPP requires placing a control panel called Config PPP in your Control Panels folder, and an extension called PPP in your Extensions folder. If you drop them on your closed System Folder, System 7 automatically places them in the proper folders. After you've installed Config PPP and PPP, restart your Mac.
Installing InterSLIP requires placing an extension called InterSLIP in your Extensions folder. If you drop it on the System Folder icon, System 7 places it in the correct location. The application called InterSLIP Setup can live anywhere on your hard disk, but it may be a good idea to put it or an alias to it in your Apple Menu Items folder, for easy access. After you place those files in the proper places, restart your Mac.
If you aren't installing MacPPP or InterSLIP, simply restart now. When the Mac comes back up, open the MacTCP control panel from the Control Panels folder (see figure 17.1).
Figure 17.1: MacTCP control panel.
Note: If you've installed InterSLIP rather than MacPPP, you have an icon labeled InterSLIP instead of PPP in the MacTCP control panel main window. I have additional icons because of my direct Internet connection.
You must select one of the connection method icons (you may have more, fewer, or different ones) in the upper part of the control panel to tell MacTCP how you plan to connect. If you have a LocalTalk network attached to the Internet through a router, select the LocalTalk icon. If you have an Ethernet connection, select that icon. If you use MacPPP, select the PPP icon. And, of course, for a SLIP connection, select the InterSLIP icon.
Note: Do not install MacPPP and InterSLIP at the same time -- they seem to confuse MacTCP if both are available. Also, if you want to switch between the two, completely reinstall MacTCP before switching.
If your provider gives you a Manually-addressed account (a static address) and provides your IP address, type the address into the IP Address field where you selected the connection method. If your host machine assigns you an address (a dynamic, or Server-addressed account), leave this field alone, since MacTCP fills it in when you actually make a connection and are assigned an IP address by the server. Not too hard yet (I hope).
Now click the More button in the MacTCP control panel to bring up the configuration dialog box (see figure 17.2).
Figure 17.2: MacTCP configuration dialog.
Remember that I said to ask whether your address was obtained Manually, from your Server, or Dynamically? The answer is the setting for the Obtain Address set of radio buttons. Select the button that corresponds to what your system administrator tells you.
Time for a brief talk about those Obtain Address buttons. Everything I have read or been told has advised avoiding the "Dynamically" button like the plague. The problem has to do with the fact that when you use it, MacTCP makes up an address at random and then looks for duplicate addresses. Apparently, this process tends to fail and can result in duplicate IP addresses on the network at the same time, which is a bad thing. The situation is actually somewhat more complex, but suffice it to say that you should never select the Dynamically button unless your network administrator explicitly tells you to and provides a range of addresses from which MacTCP can choose. I've never heard of any Internet access providers using the Dynamically button with SLIP or PPP accounts.
If you click on the Manually button, you must enter, in the outer control panel window, the permanent IP address that your system administrator has provided for you. Either use the Manually button or the Server button, and remember that if your system administrator talks about dynamic addressing, he probably means what MacTCP calls a Server-addressed account.
Enough about the Obtain Address buttons. If your system administrator gives you a gateway address, type it into the Routing Information Gateway Address field. If you use a Server-addressed account, you can't type in the Gateway Address field, so don't worry about trying to. Again, MacTCP fills it in when you connect.
Note: If you use MacTCP with MacPPP or InterSLIP, there's no way to affect this field, but with VersaTerm SLIP, you can set the Gateway Address, even if you use a Server-addressed account.
The large IP Address area in the upper right certainly looks hairy, but for most people, there's no need to touch anything in this area. That's the good news.
The bad news is that if you do have to mess with this section of the dialog, you need help from your administrator. You may have to set the correct network class (the pop-up menu containing A, B, or C) and the subnet mask (the slider bar beneath the title in the dialog box) manually. Primarily, large networked sites must deal with subnet masks because they sometimes use a method called subnetting to handle their IP networks. If you have subnetting at your site, you also have someone who knows something about it and can provide details of how to configure MacTCP for your site. Be sure to ask nicely!
You must fill in the Domain Name Server Information section with the name of your domain and the IP numbers of your name servers.
Note: The domain name server is used every time you use a program to connect an Internet site by name. So, if you use Anarchie to connect to ftp.tidbits.com, the domain name server looks up ftp.tidbits.com and sees that its IP number is 192.135.191.2. Since the computers always use IP numbers and people usually use domain names, the domain name server is an essential part of the MacTCP-based connection.
As you can see previously in figure 17.2, I have access to a number of name servers. Unfortunately, the interface for this section of MacTCP is quite confusing. Let me try to explain it as best I can.
Note: Warning -- this stuff gets pretty technical, so if you're not interested and everything works properly after you install MacTCP, just skip it. I use the halcyon.com domain as an example here, but if you don't use Northwest Nexus, you undoubtedly will have a different domain, and you will also of course have different IP numbers for your domain name servers.
For each entry in the MacTCP Domain Name Server Information area, there are two fields and a Default radio button. The left-hand field holds a domain name (not the name of a domain name server!). The right-hand field holds the IP numbers of domain name server that MacTCP uses to look up addresses in the domain listed in the left hand-field. Only one of the radio buttons can be selected at a time, and MacTCP uses the line containing the selected Default radio button as your default domain name server. So, when I put halcyon.com. in the first left-hand field, I'm telling MacTCP to use the name server at 198.137.231.1 for all requests within the halcyon.com domain. In other words, the domain name server at 198.137.231.1 is used only if the name that you're looking up ends in halcyon.com
The domain name you enter in that first left-hand field is also the domain name that MacTCP tacks on the end if you use a single word name, such as coho. The utility of this is that I could say, telnet to the machine coho.halcyon.com by merely entering coho in NCSA Telnet's connection dialog. This isn't particularly helpful in normal usage.
Note: This process of using only the first name of an Internet machine, say, coho, also is called using unqualified domain names. A full name like coho.halcyon.com, in contrast, is called a fully qualified domain name.
Make sure to select the Default button next to this first entry. This button has two tasks. First, it identifies the domain that MacTCP uses to complete unqualified domain names, as mentioned above. Second, it ensures that the domain name server in that line, 198.137.231.1, is used if, and only if, no other lines in the domain name server configuration match the request. Reflect on this briefly while I get to the next few lines, since they interact with one another.
Note: You may have noticed the period after the halcyon.com domain in the screenshot. That period positively denotes an absolute domain, as opposed to one that's relative to the current domain. However, MacTCP currently treats all names that contain at least one period as absolute names, so it makes no difference at all now. It does on other systems, and it may with MacTCP in the future; hence, it's a good idea to get in the habit of appending that last period.
Next, look at the second set of fields. In the left-hand field I have a period, and the right-hand field, I have exactly the same IP number as the first right-hand field. This second line is necessary because the first line (the primary name server) won't be used for requests outside of the domain listed in the first line. By duplicating the IP number, we tell MacTCP to use this name server for all requests outside the halcyon.com domain. Keep all this in mind while we look at the third line.
The third set of fields have another period in the left-hand field and a different IP number, 192.135.191.1, in the right-hand field. This denotes my secondary name server, the name server that MacTCP queries if it doesn't get anything back from the first one.
Okay, now we have all the pieces to make sense of this confusing configuration interface.
If a program asks for the IP number for a machine in the halcyon.com domain, MacTCP asks the machine in first line (the primary name server) to handle the request. If MacTCP asks for the IP number for a machine anywhere outside of the halcyon.com domain, the second line handles the request. Finally, if the main name server is down, rendering the first two lines ineffective, the secondary name server in the third line kicks in to look up the IP number in question. Although the second line may seem redundant, it's not. If you didn't have it and asked for the IP number of a machine outside of the halcyon.com domain, that request would go directly to the secondary name server. If that name server were down, your request would fail.
Note: You can't see it in the screenshot, but I actually have a fourth line with yet another period in the left-hand field and a different IP number in the right-hand field. It handles requests if the first two name servers are down. You can have three or more name servers, but that many aren't generally necessary
I did run into an interesting problem when helping a friend with MacTCP. He could connect to FTP and Web sites on the Internet just fine, but he couldn't get his mail, and when we checked, he couldn't connect to his provider's Web server either. It turned out that he had only two entries in his MacTCP Domain Name Server Information section, and both were wrong in such a way that lookups outside of his domain worked fine, but every time a program tried to look up a host within his domain (such as his SMTP server or Web server), it failed. So pay close attention when configuring your domain name servers -- it can cause some quirky problems if configured incorrectly.
Note: The most recent version of MacTCP, version 2.0.6, introduced a situation where it will fail to resolve domain names that contain the underscore character. This is actually the correct behavior because the underscore shouldn't be used in a domain name, but a few sites did use it. Luckily, after MacTCP 2.0.6 was released, most of those sites renamed the offending machines.
After you're done with all that domain name server information, click the OK button to save your changes, and then close the MacTCP control panel. Depending on what you change and if you've used MacTCP yet that session, MacTCP may tell you that the changes won't take effect until you restart. Go ahead and restart your Mac if necessary. If I'm troubleshooting, I usually restart every time I reconfigure MacTCP whether it tells me to or not, just to be safe.
After you configure MacTCP and restart your Mac, it creates two files. One, called MacTCP DNR, is loose in your System Folder, and the other, called MacTCP Prep by default , is in your Preferences folder. MacTCP creates both files from scratch if you delete them and doesn't lose any settings in the process, because it stores settings both in its control panels and in the MacTCP Prep file. Deleting these files is a must when you're troubleshooting or upgrading to a new version of MacTCP.
Note: MacTCP DNR stands for Domain Name Resolver. If you want to know more, turn on Balloon Help and point to that file with the arrow. Suffice it to say that throwing out the MacTCP DNR file and restarting can solve some weird MacTCP problems.
The MacTCP Prep file bears some additional discussion. As I said above, when you configure MacTCP, it stores its settings in both the MacTCP control panel and in the MacTCP Prep file. Although this may seem unnecessary, it has a useful side effect. Since MacTCP reads its settings preferentially from the MacTCP Prep file, you can keep multiple MacTCP Prep files handy for working with different providers. Most people won't need this capability of course, but for those that do, it comes in handy. For instance, when I'm traveling, I use different dialup accounts in different cities. I could use a utility like MacTCP Switcher or MacTCP Netswitch, but since I don't travel all that frequently, I usually just pull out my old MacTCP Prep file and replace it in the Preferences folder with one customized for the new Internet access provider.
It appears that you also can rename the MacTCP Prep file, which makes it easier to keep several different copies around. However, if you keep them in your Preferences folder, MacTCP preferentially uses the one called MacTCP Prep over any version with a modified name.
Domain name servers didn't always exist, and before they did, each computer had a Hosts file that contained the IP names and numbers of all the Internet machines you could contact. When a program needed to translate an IP name into an IP number, it looked in the Hosts file for that information (and it failed unless the machine you wanted to connect to was listed). This worked fine when there were only several hundred machines connected to the Internet. In these days with millions of machines connected to the Internet, the Hosts file isn't as good a solution as the domain name server, but because there are still instances where people can't contact a domain name server, the Hosts file has remained with us.
Note: Theoretically, you can use any Internet machine that is a domain name server as your domain name server, although if it's not local, the domain name server lookups may be quite slow.
If you don't have a domain name server (but most people do), you must use a Hosts file, which lives loose in the System Folder on the Mac. If you do have a domain name server and configure the Domain Name Server Information in MacTCP appropriately, you don't need the Hosts file at all because your Mac can ask the domain name servers for addresses rather than look them up in the Hosts file. Using the Hosts file can be dangerous if you don't need it, in fact, because it stores hard-coded information about which machines use which IP numbers, and if that information changes, the Hosts file will provide incorrect information to MacTCP. I've been bitten by this in the past, and don't recommend you install a Hosts file unless you know you need to.
Note: One instance when you can't access a domain name server is if you're behind a firewall, which is a security system in which everyone must go through a secure host machine that is the only one in an organization connected to the Internet.
If you want to use the Hosts file, you must manually enter all the hosts to which you may want to connect, along with their IP numbers. You can edit the Hosts file with TeachText or SimpleText, but make sure to create the host entries in exactly the same manner as shown in the examples. In any event, here's what a standard host entry looks like:
consultant.micro.umn.edu. A 134.84.132.4 ;
Note: The Communications Toolbox Telnet tools like to use the Hosts file as a repository for Internet machines that you have connected to previously. In fact, the VersaTerm Telnet tool adds sites to the Hosts file for you, if you enter them into the tool's configuration dialog.
A few utility programs have appeared that help you troubleshoot your Internet connection. In addition, a couple of utilities, MacTCP Switcher and MacTCP Netswitch, help ease the process of switching between two completely different MacTCP setups, such as you might have if you use Ethernet at work and PPP at home. Unless mentioned otherwise, the latest versions of these utilities can be found in:
ftp://ftp.tidbits.com/pub/tidbits/tisk/tcp/
Along with their shareware software, Dartmouth College has some commercial quality applications that they sell. Included in this category are the $99 MacPing 3.0 and the $399 MacPing 3.0 Pro, ping utilities that work with both AppleTalk and TCP/IP networks such as the Internet. MacPing 3.0 is limited to testing five AppleTalk zones, whereas MacPing 3.0 Pro can test an unlimited number of AppleTalk zones. They're otherwise identical. Not being a network administrator, I'm not really sure what MacPing tells me, but I gather that by watching the way the pings come back from all the machines, you can tell where there might be a network problems. Check out its help text for more information about what all the parts of the window do. For ordering information contact True BASIC, Inc., the MacPing distributors, at 800/436-2111 and check out the demo at the FTP URL below.
ftp://ftp.dartmouth.edu/pub/mac/
MacTCP Watcher is a free program written by the prolific Peter Lewis to display the internals of MacTCP's workings. You must be an expert to decipher most of this information, and Peter claims that even he doesn't know what most of it means. However, if you're having troubles with MacTCP, MacTCP Watcher proves to be one of the best tools available for troubleshooting a bad connection. I still don't understand what it complains about, but it tends to react in specific ways to specific problems, and those reactions are usually more useful than the generic error messages that come back from other programs. MacTCP's other functions include a ping test, which is a bit like sonar over a network. It's useful for determining whether a remote machine is up, and if so, about how far away it is (or how slow the network to it is). The UDP and TCP tests mean less to me, but I use MacTCP Watcher's DNS button to match IP names and numbers. So, definitely pick up MacTCP Watcher, and poke at the buttons to see if anything that comes back looks useful. I always have a smashing good time looking at stuff I don't understand.
The free MacTCP Netswitch control panel, written by David Walton, of the University of Notre Dame, appears to be the more sophisticated of the two utilities for switching between MacTCP connections. It works by sensing at startup whether you're connected to an AppleTalk network, and if so, what zone you're in. After it's sensed whether you're in a network or not, it swaps in an appropriate MacTCP Prep file from a group of preconfigured ones. The major advantage of the way MacTCP Netswitch senses the environment at startup is that theoretically you don't have to restart, because it has forced MacTCP to load the proper MacTCP Prep file at startup.
http://www.nd.edu/~dwalton1/netswitch.html
John Norstad's free MacTCP Switcher requires a bit more interaction from the user than MacTCP Netswitch. After you have MacTCP set up properly, you run MacTCP Switcher and save a configuration file that records the current MacTCP settings. Do the same for your other configurations. To restore a saved configuration, double-click it in the Finder, and when MacTCP Switcher prompts you, click the Set MacTCP button to set MacTCP to use the saved configuration. Another alert then appears telling you that MacTCP has been set; it may also tell you to restart your Mac, and if so provides a Restart button to do so instantly. MacTCP Switcher doesn't work with whole MacTCP Prep files, as MacTCP Netswitch does, but instead copies the relevant resources from the MacTCP Prep file to the configuration file and back again. It never touches the MacTCP control panel itself.
Chris McNeil, has a free, easy to use, and potentially useful program called Query it! that enables you to query your local nameserver to find out more information about various Internet hosts. The most useful piece of information you can get from Query it! is the IP address for a host, the number that goes with the name. For instance, I asked Query it to tell me the address of halcyon.com. That's all there is to Query it!, although you can see if the CNAME, HINFO Record, or MX Record results are of interest to you.
Apple hasn't yet released Open Transport, the successor to MacTCP, but I was able to take a look at a pre-released version for this chapter. The good news is that although MacTCP isn't that hard to configure once you understand what's going on, Open Transport is much easier to configure than MacTCP. To compare Open Transport and MacTCP is a bit misleading though, since Open Transport is a complete rewrite of the entire communications infrastructure on the Macintosh.
Open Transport's primary goal is to support multiple networking protocols (including AppleTalk, TCP/IP, and other mishmash acronyms like SNA, DECnet, OSI, and X.25) in such a way as to insulate the user from the details and to simultaneously provide a single coherent target for developers.
Most of the changes in Open Transport take place below the surface, so it's a little hard to say too much about it until Apple releases it, perhaps in the summer of 1995. However, based on statements that Apple has made about Open Transport in a public white paper, I can tell you the following about Open Transport.
All of that said, for most users, Open Transport's most obvious improvement on MacTCP will be the new, simplified interface (see figure 17.3).
Figure 17.3: Open Transport TCP/IP Configure Manually settings.
As you can see in figure 17.3, the new interface provides two pop-up menus, one that specifies how you want to connect to the Internet and another that specifies how your configuration information will be entered. In figure 17.3, I chose to connect via Ethernet and to configure everything manually, which meant that I had to fill in my IP Address, Domain name, Router address, and Name server address.
Although you use the same information in configuring MacTCP, the new interface is obviously quite a bit easier to understand. However, if you can use the new DHCP method of automatically configuring Open Transport, you can see in figure 17.4 that your work almost disappears.
Figure 17.4: Open Transport TCP/IP Configure Using "DHCP" settings.
Configuration using BootP is similarly easy, and if you connect via an AppleTalk network at a large organization, a MacIP server can again provide all the configuration information automatically (see figure 17.5).
Figure 17.5: Open Transport TCP/IP Configure Using MacIP Server settings.
Note: Apple reportedly plans Open Transport to be a free upgrade for existing MacTCP owners, including readers of this book. Open Transport will also undoubtedly be bundled with future versions of the Mac OS and all new Macs once Apple releases it, so it shouldn't be too hard to get to that point.
Phew! That's about it for configuring MacTCP. In most cases, MacTCP is really quite easy to configure once you know what information goes into which fields in the Configuration dialog. I provided all of the information above, even though most people should never need it, because if you do need to figure out what's going on in MacTCP, you need the details. If you use one of the providers listed in appendix A, "Internet Starter Kit Providers," and MacPPP, the ISKM Installer configures MacTCP for you. Speaking of MacPPP, let's talk about PPP next.